Frontend security hardening html sanitization & vulnerability linting #164
Conversation
|
HI Harsh, I’m happy with removing the legacy Vulnerability_Tool and the .docx artefacts , they weren’t used by CI and this reduces repo noise. Replacing that with npm audit in CI makes sense for maintainability. Before I approve, could you please confirm two small things: multer upgrade: since this can affect upload behaviour, can you confirm either (a) upload endpoints still work as expected, or (b) we don’t rely on multer-based uploads in this repo? Token expiry comment: accessTokenExpiry is now 10m (more secure ), but the inline comment still says “15 minutes” , please update it for consistency. Once those are confirmed/fixed, tag me and I’ll approve straight away Thanks |
2 participants
dompurify
What it is: A library that sanitizes HTML.
Why it's needed: If your application ever renders HTML content dynamically (for example, displaying a user's bio or a formatted article from your API), hackers can try to inject malicious scripts (Cross-Site Scripting or XSS). dompurify strips out dangerous tags (like <script>) while keeping safe HTML (like or
) intact.
@types/dompurify
What it is: The TypeScript type definitions for dompurify.
Why it's needed: Even if you are writing standard JavaScript, modern code editors (like VS Code) use these types to provide autocomplete suggestions and error checking. It ensures you are using the dompurify library correctly.
eslint-plugin-security
What it is: A plugin for ESLint (the tool that checks your code for errors).
Why it's needed: It acts like an automated security guard that watches you code. It scans your source code for patterns that are known to be insecure, such as: